REMARKS 

This supplemental response is intended as a full and complete reply to the Office Action 
dated April 28, 2009, for which a response was filed June 22, 2009, in light of the interview of 
October 20, 2009. 

Claims 1-4 are currently amended in this response. 

Claims 5-130 are cancelled. 

Claims 131-144 are newly added in this response. 

Claims 1-4 and 131-144 are currently pending in the Application. 
Claim Objections 

The previous Office Action objected to Claims 2-4 and 15 as being of improper dependent 

form. 

Claim 15 has been cancelled. 

As best understood, Applicant believes the objection relates to the recitation "for 
reconciling" within the preamble of Claims 2-4, which was inadvertently not amended when the 
preamble of Claim 1 was amended previously. Applicant has amended Claims 2-4 to remove the 
recitation "for reconciling" from the preamble of each of the aforementioned claims. 

Applicant believes that no further amendments are necessary to correct the form of Claims 
2-4. Claims 2-4 further limit the recitation "actual performance data," found in Lines 2, 6, 8, and 
9 of Claim 1, above, and otherwise include all limitations of Claim 1. As such, Applicant 
believes Claims 2-4 properly depend from Claim 1 . 
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Claim Rejections - 35 USC §112 

The previous Office Action rejected Claims 1-4 and 15 under 35 USC §112, first 
paragraph, as failing to comply with the written description requirement. Specifically, the 
Office Action noted that the recitations "electronic comparison circuitry" and "complex project" 
are not found in Applicant's Specification. Applicant respectfully traverses this rejection. 

With regard to the recitation "electronic comparison circuitry," Applicant has amended 
Claim 1 to clarify that the processor is used to compare the actual performance data to the 
estimated data to determine any discrepancy. This amendment is supported by the disclosure of 
original Claims 21, 28, and 63, as filed, and throughout the Specification. 

With regard to the recitation "complex project," Applicant would submit that sufficient 
support exists in the specification, as filed, to substantiate this term, as used in the Claims. 

Paragraph [0008] references that "[a]s is appreciated by those skilled in the art, 
converting specifications for complex projects into specific requests for goods/services is 
extremely time consuming, is often incomplete, and is extremely inefficient ... a process is 
needed that enables a buyer to procure those goods/services necessary to undertake and 
complete a project . . ." 

Paragraph [0091] recites: "Since delays, rescheduling, and substitutions of goods/services 
often occur when undertaking a complex project (for example, drilling an oil well), the process 
also provides for the adaptation of contractual terms, as necessary, by allowing both parties (the 
buyer and seller) to monitor the progress of the project at any time via a common database." 

Paragraph [0106] recites: "As may be appreciated, for complex projects, such as drilling 
an oil well, the Parameters may be reviewed and modified by numerous geologists, engineers, 
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rig operators, and others prior to the generation of actual requests for goods/services (Block 
342)." 

Paragraph [0149] recites: "Other types of complex projects, i.e., other than the oil and gas 
industry example, may have different components with greater or fewer steps or templates to 
adequately and accurately capture and describe the Parameters of any particular project and 
convert those Parameters into RFQs 718." 

Further, the disclosures of the applications having serial numbers 09/672,938, 
60/236,998, and 60/187,345, incorporated within Applicant's Specification by reference (See 
Paragraph [0001]), contain additional support for the recitation "complex project." 

The Office Action rejected Claims 1, 4, and 15 under 35 USC §112, second paragraph, as 
being indefinite. Specifically, the Office Action noted that the recitations "actual performance 
data" of Claim 1 and the recitations "measurement" and "parameter" of Claim 4 are unclear and 
indefinite. Applicant respectfully traverses this rejection. 

With regard to the recitation "actual performance data," throughout the Specification, 
Applicant refers to actual performance data, the term "actual" used to contrast certain items of 
data with estimated data. Claim 1 has been amended to further clarify this distinction by 
referencing that the actual performance data comprises an indication of goods, services, or 
combinations thereof used for performance of at least a portion of a complex project. 

The term "actual performance data" is further clarified and supported, for example, by 

Paragraph [0153], which states: 

"When the seller completes performance on the project, it provides actual performance 
data 748 to the IBE system 700. This actual performance data preferably includes both 
costs for the goods and services provided, and information about the conditions 
encountered that the Parameters attempted to define. Actual performance data can be 
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provided by seller-side systems 750 such as accounting programs, and in the case of oil 
and gas projects, electronic field ticket entry (described later herein in detail). In the oil 
and gas industry, a field ticket captures many of the actual results of a project, both 
financial and functional. In general, field ticket or actual data consists of measurements 
or observations taken during the performance of the project. In a preferred embodiment, 
such actual data observed may be provided to the IBE system using wireless processing 
and communications technologies. The actual performance data is used to update the 
configuration Parameters 752 with the actual information to aid in the request process for 
future projects involving the same or similar parameters. This actual information may 
further be stored by the buyer system 754 for historical reference purposes. The actual 
cost information is also used by the IBE system 700 to reconcile 756 purchase orders, 
field actuals, and final invoices to provide appropriate payment by buyers to sellers for 
the completed project." 

Applicant would submit that upon a reading of Claim 1, as clarified by the Specification, 
the term "actual performance data," is sufficiently recited and explained throughout the 
specification, and is not indefinite. 

With regard to the recitation "parameter," Applicant would submit that this term is not 
varied or indefinite. As described throughout the Specification and original claims, as filed, a 
parameter can be any feature or component relating to a complex project, including physical, 
functional, temporal, transactional, and/or geographical parameters. (See, e.g., Original Claim 
16) Each project is defined in terms of one or more parameters. (See, e.g., Original Claim 33) 

The term "parameter" is further clarified, defined, and supported by Paragraph [0015], 

which provides numerous examples, and states: 

"More specifically, when utilizing the systems and/or processes of the present invention, 
a buyer specifies parameters that describe a project. Examples of such parameters include 
the following: physical parameters (e.g., size, weight, height); functional parameters (e.g., 
able to accelerate from 0 to 60 m.p.h. in less then 6.0 seconds); temporal parameters (e.g., 
to be delivered by Tuesday); financial parameters (e.g., to cost less than $10.00); 
transactional parameters (e.g., to be paid by check or money order); and/or geographical 
parameters (e.g., located in Colorado). The physical, functional, temporal, financial, 
and/or geographical parameters , or any other Parameters that may be appropriate for 
completion of the project, are hereafter collectively referred to as " Parameters ." 
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Each parameter can have a specified value, measurement, or specification, but the 
identity of each parameter, itself, is not variable or indefinite, nor is the term "parameter" 
indefinite. (See, e.g., Paragraph [0002], stating "... the present invention relates to an 
automated process that receives specifications of physical, functional, temporal, financial, 
transactional and/or geographical parameters from buyers, and matches the buyers with sellers 
of such goods and/or services that satisfy the parameters and specifications.") 

With regard to the recitation "measurement," as described above and throughout the 
Specification, each parameter has a value. Claim 4 relates to a method for reconciling actual 
performance data, the actual performance data being comprised of one or more parameters, each 
parameter having a measurement. Each measurement is a definite value relating to the 
associated parameter. Claim 4 utilizes the term "measurement" to describe any value that could 
apply to the associated parameter (see, e.g. Paragraph [0015], copied above). Applicant would 
argue that use of the term "measurement" in this manner, to encompass a variety of possible 
values for a parameter, is commonplace among applications for patent, and that Applicant is not 
required to limit Claim 4 to any specific value. 

Claim Rejections - 35 USC §103 

The previous Office Action rejected Claim 1 under 35 USC § 103(a) as being unpatenable 
over Puri et al. (7,440,909) in view of Ockman (4,700,318). Applicant respectfully traverses 
this rejection. 

Claim 1, as amended, recites a method for procuring one or more goods and/or services 
for a complex project in which actual performance data of the complex project is compared with 
estimated data related to the complex project, to determine the existence of any discrepancies, 

12 



and to enable reconciliation of these discrepancies. Applicant's method is specifically adapted 
for use with complex projects, which typically involve goods and/or services that are requested 
by a buyer, but are received through any number of potentially variable performances by the 
seller. Numerous characteristics of performances, by both the buyer and the seller, can vary 
during the performance of a complex project. As such, estimated data can be associated with a 
complex project to facilitate an initial request and/or payment, however actual performance data 
relating to the end result of a complex project can, and often will, differ from the estimated data 
by the very nature of a complex project, such as the drilling of an oil well. When such 
discrepancies are noted, it is necessary for the seller to reconcile these discrepancies with the 
buyer. No existing method is adapted to reconcile these complex projects in the manner 
described by Applicant. 

Specifically, Claim 1 recites a method that is adapted for reconciling complex projects, in 
contrast to discrete transactions for goods and services involving non-variable performances. 
Estimated data relating to the complex project is obtained and stored, from any source relating 
to the complex project. The estimated data includes an initial estimate of the goods and/or 
services required for performance of at least a portion of the complex project. For example, 
estimated data could include the information contained within an initial purchase order. Actual 
performance data is then stored. The actual performance data includes an indication of the 
goods and/or services actually used for performance of the related portion of the complex 
project. For example, the actual performance data could include information normally included 
in any number of invoices and/or field tickets. The actual performance data is then compared to 
the estimated data to determine a discrepancy therebetween, and a notification of the 
discrepancy is sent to the seller and/or the buyer. A proposed reconciliation is then received 
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from the buyer and/or the seller, which the other party can manually or automatically approve or 
disapprove. 

In the event that the proposed reconciliation is disapproved, documents related to the 
transaction can remain alive even though the related portion of the complex project has been 
performed, such that the buyer and seller can continue to communicate, negotiate, make 
changes to documents, propose alternative reconciliation, or simply account for the discrepancy. 
(See, e.g., Applicant's Specification as filed, Paragraphs [0196] - [0198]). 

For example, when performing a cementing operation on an oil well, it may be initially 
determined that a first quantity of cement is needed, based on the depth of the well and other 
parameters. When performing the cementing operation, it may be determined that due to other 
factors, such as the temperature or pressure of the well, additional cement, additives, or other 
products or services may be needed. To avoid a costly cessation of drilling operations, a field 
ticket for the additional goods and/or services can be approved contemporaneously, on-site. 
Following completion of the cementing operation, the initial purchase order will differ from the 
actual goods and services provided, creating a discrepancy for which reconciliation is necessary. 
When performing a complex project, such as operating an oil well, many such transactions are 
required, resulting in a large number of discrepancies that must be reconciled. The method 
recited by Claim 1 enables any such discrepancies to be electronically identified and reconciled, 
providing significant improvements over conventional invoicing and accounting procedures that 
would otherwise be required. 

Puri instead relates to an invention that provides a fixed bill of materials and retrieves 
real time costing data relating to these fixed materials. Puri attempts to compensate for 
variations in the cost or value of these selected materials by maintaining real time costing data, 
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but does not allow for variable performances by both buyers and sellers, such as variations in 
the materials. 

Specifically, Puri describes an accounting method used to collect and present real time 
data, through which differing methods for accounting costing can be utilized for actual cost 
collection and cost presentation. (Puri, Column 1, Lines 10-15) Actual costs of performing a 
job and obtaining and/or manufacturing an item associated with a business activity are 
collected, a unique cost identifier is created and associated with the cost, and based upon the 
cost identifiers, differing accounting costing methods for cost collection and cost presentation 
can be selected. (Puri, Column 2, Line 66 - Column 3, Line 16) 

In the method described by Puri, no estimated data is obtained, and no comparison 
between estimated data and actual data is performed. Puri teaches away from obtaining 
estimated data and comparing estimated data with actual performance data to reconcile a 
transaction. Instead, Puri speaks to the limitations of using estimated data with a fixed bill of 
materials, and seeks to use only real time actual costing information to avoid these limitations. 
(Puri, Column 2, Lines 15-21) As such, no reconciliation for discrepancies between estimated 
data and actual performance data, or approval or disapproval thereof, is taught by Puri. Puri 
instead teaches away from reconciling such discrepancies by disclosing a system that attempts 
to avoid the use of reconciliation through the exclusive use of contemporaneous, real-time 
costing data. 

Unlike Applicant's method, Puri does not recognize the problems to be solved when 
reconciling a complex project, which require use of both estimated data and actual performance 
data to account for expected changes that occur during performance of a complex project. 



15 



Therefore, Puri fails to teach numerous elements of Claim 1 . Specifically, Puri does not 
teach a method for reconciling complex transactions, as taught by Applicant. Instead, Puri 
relates to accounting for discrete items of a bill of materials (i.e. performing a job, 
manufacturing an item), rather than any type of transaction, much less a complex transaction. 
(See, e.g. Puri, Claim 1) 

Puri further does not teach obtaining and storing estimated data, Puri instead describing a 
need to eliminate use of estimated data and instead collect real time data relating to actual costs. 
As such, Puri also does not teach comparing estimated data to actual data, providing notice of 
any discrepancies therebetween, or receiving a proposed reconciliation and approval or 
disapproval thereof. The method of Puri is not designed, intended, or capable of managing and 
reconciling one or more transactions of a complex project. 

As such, the combination of Puri with Ockman is improper, as Puri teaches away from 
comparing estimated and actual data to reconcile discrepancies. (See, e.g., Puri, Column 5, 
Lines 1-4, which states "In contrast, standard costs offer the accountant or decision-maker what 
is frequently an inaccurate estimation of future costs based on historical data.") The addition of 
material from Ockman to add estimated data, and notification and reconciliation of 
discrepancies between estimated data and actual data, contrary to the teachings of Puri, would 
render the system and method of Puri nonfunctional. 

However, independent of the improper combination of Ockman with Puri, Ockman fails 
to teach each element of Claim 1 not taught by Puri. Therefore, the combination of Puri and 
Ockman fails to render Applicant's Claim 1 unpatentable. 

Ockman describes a system used to visually depict the components, jobs, and 
interrelationships between the various parts of a construction process, to overcome language 
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barriers and graphically display information that is difficult to intelligibly communicate using 
language alone. (Ockman, Column 1, Lines 15-33) A project schedule and current project data 
are stored in separate memory areas, and the two memories can be compared to identify 
differences between a current schedule and an original or interim target schedule. (Ockman, 
Column 3, Lines 52-67) Depicted structural features are displayed in a manner characterized by 
scheduling concerns, and any items overdue for completion or that otherwise deviate from the 
schedule can be visually emphasized. (Ockman, Column 2, Lines 23-37) 

Ockman does not teach a method for reconciling complex transactions, as taught by 
Applicant. Instead, Ockman relates to an overall graphical display of a project as it was 
intended to occur, compared against a graphical display of the current status of a project. (See, 
e.g. Ockman, Claim 1 and Column 2, Lines 23-62) 

The system of Ockman is not designed, intended, or capable of managing and reconciling 
one or more transactions within a complex project, as taught by Applicant. The only 
characteristic of a project managed by the system of Ockman is the scheduling of discrete 
projects in relation to other discrete projects. Any projects that are not on schedule are bolded 
and/or shaded. (See, e.g. Ockman, Claim 1) As such, Ockman does not teach receiving a 
proposed reconciliation and approval or disapproval therereof, to enable reconciling of 
discrepancy within a transaction of a complex project, as taught by Applicant. 

Therefore, neither Puri, Ockman, nor the combination of Puri and Ockman teach each 
element of Claim 1, as amended. Further, as described previously, the combination of Puri and 
Ockman is improper, as Puri teaches away from Applicant's claimed method, and the teachings 
of Puri are contrary to a combination with Ockman, which would hinder or render non- 
functional the system and method of Puri. 

17 



Applicant believes that Claim 1, as amended, in light of the remarks presented, is 
patentable over Puri in view of Ockman and respectfully requests reconsideration of the instant 
rejection. 

The previous Office Action rejected Claims 2-4 and 15 under 35 USC § 103(a) as being 
unpatenable over Puri et al. (7,440,909) in view of Ockman (4,700,318) and further in view of 
Huberman (5,826,244). Applicant respectfully traverses this rejection. 

Huberman fails to teach the elements of Claim 1 not taught by Puri and Ockman. 

Huberman relates to an auction system, which by definition includes a binding price for a 
specified amount of goods or services, the winning price and the goods and services for sale 
both not subject to variance. As such, Huberman does not address the problems presented by a 
complex project. 

Specifically, Huberman describes a document distribution and auction system relating to 
transactions for obtaining document services (i.e. printing, copying, etc.). (Huberman, Column 
1, Lines 12-22) A broker process acts as an intermediary between a customer process and a 
supplier process, the broker process being provided with a description of a desired document 
service. (Huberman, Column 2, Line 64 - Column 3, Line 3) Responsive to the description, an 
auction is conducted in which a customer or supplier submits a bid, and the broker process 
establishes a price and proposes a transaction based on the established price, which can then 
occur automatically. (Huberman, Column 3, Lines 3-14) 

Huberman does not teach a method for reconciling complex transactions, as taught by 
Applicant. Instead, Huberman relates to auctions for discrete, non-complex services, such as 
performing printing, copying, or shredding jobs. (See, e.g. Huberman, Column 1, Lines 12-22) 
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Additionally, Huberman does not teach obtaining estimated data, nor actual performance 
data, as Huberman relates to an auction process in which a transaction is proposed, but does not 
relate to the actual performance of the transaction. As such Huberman also does not teach 
comparing estimated data to actual performance data or receiving a proposed reconciliation for 
a discrepancy and approval or disapproval thereof. 

Applicant would therefore also submit that the combination of Huberman with Puri and 
Ockman is improper. Any cost, accounting, or measurement-related data obtained in relation to 
an auction conducted using the system and method of Huberman would not constitute estimated 
data or actual performance data, as taught by Applicant. No motivation exists to combine 
certain aspects of dissimilar data obtained through the auction system of Huberman with the real 
time accounting system of Puri and/or the visual scheduling system of Ockman. 

Claims 2-4 depend from Claim 1 and contain all limitations thereof. Because Applicant 
believes Claim 1 is patentable over Puri and Ockman in view of Huberman for the reasons 
described above, Applicant also believes Claims 2-4 are patentable over the art of record. 

Additionally, as the combination of Puri, Ockman, and Huberman is improper, for the 
reasons described above, Applicant also asserts that the combination of Puri, Ockman, and 
Huberman fails to teach any of Claims 2-4 individually. Reconsideration of the above rejection 
is respectfully requested. 
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Additional References 

During the interview of October 20, 2009, the following references were brought to the 
attention of Applicant, and remarks relating to each of the references were requested: 

1) Oracle Method Project Management Handbook (March 1999 [hereafter "Oracle"]); 

2) Whitemarsh Project Management: Architecture and Concept of Operations (1999) 
[hereafter "Whitemarsh"]; and 

3) Hendrickson et al., "Project Management for Construction Fundamental Concepts for 
Owners, Engineers, Architects, and Builders," (1988) [hereafter "Hendrickson"]. 

Oracle relates, generally, to a system for planning and controlling information technology 
projects, which are subject to changes in technology. (Oracle, Page 1-2). Each project task is 
classified as a planning task, which defines a project's scope, a control task, which is performed 
concurrent with execution steps in furtherance of the project, or a completion task, which ends a 
project and formalizes acceptance of deliverables. (Oracle, Page 1-5). Project planning and 
completion steps are each performed at the beginning of a task, and at the task's end. (Oracle, 
Page 1-9). The project plan serves as the basis against which quality audits are performed. 
(Oracle, Page 2-15). 

The project plan is formed using generally fixed client requirements, contractual 
agreements, costs, and other factors. (Oracle, Page 3-5). Oracle references the existence of risk 
when forming a project plan, but does not disclose the expectation of deviations from a plan and 
the need for subsequent reconciliation, and instead seeks to minimize and control risk. (Oracle, 
Pages 3-12 and 5-14). Execution of project tasks are then monitored and measured through a 
phase control process. (Oracle, Page 5-1). Completion of project tasks according to the project 
plan is then validated through a phase completion process. (Oracle, Page 6-2). 
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Oracle describes that while changes or updates in the project plan can be made, these 
changes are incorporated responsive to contractual obligations, client requests, and the like, 
rather than expected deviations after the project has begun, and adjustments to the project plan 
are made prior to each phase of a task, rather than responsive to deviations from the project 
plan. (Oracle, Pages 3-21, 4-12, and 5-6). 

Oracle fails to teach each element of the Claims. Specifically, Oracle does not describe 
obtaining estimated data comprising an initial estimate of goods and/or services required for 
performance of at least a portion of a complex project, and comparing this estimated data with 
actual performance data comprising an indication of goods and/or services actually used for 
performance. Instead, Oracle describes formation of a project plan through negotiation and 
other processes, affected by various client-imposed and resource-based factors, from which 
deviation is generally not expected. Additionally, Oracle fails to teach or suggest receipt of a 
proposed reconciliation and approval or disapproval thereof should a discrepancy from the 
project plan occur. 

Whitemarsh describes a project management system for use with information technology 
projects that can be subject to inaccurate estimates, conflicting priorities, and similar factors. 
(Whitemarsh, Page 1). A continuous flow process is proposed, through which multiple, 
disjointed projects can be scheduled and coordinated with multiple, potentially changing 
resource areas or capabilities. (Whtiemarsh, Page 5). In use, numerous application request 
packages are processed in unison, and resources are allocated or current allocations are 
modified accordingly. (Whitemarsh, Page 7). 

Whitemarsh also fails to teach each element of the claims. Unlike the claimed methods, 
Whitemarsh relates to management of multiple discrete projects where resource availability may 
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change, rather than management of complex transactions where an initial estimate of goods 
and/or services may deviate from those actually necessary, which may in turn deviate from the 
goods and services actually provided. As such, Whitemarsh does not teach or suggest obtaining 
estimated data comprising an initial estimate of goods and/or services required for performance 
of a portion of a complex project, and comparing the estimated data with actual performance 
data comprising an indication of goods and/or services actually used. Furthermore, Whitemarsh 
does not disclose identifying a discrepancy between estimated data and actual performance data, 
and receiving a proposed reconciliation of the discrepancy and approval or disapproval thereof. 

Hendrickson relates, generally, to a project management system for construction projects 
that focuses on cost efficiency for the entirety of a project rather than individual services. 
(Hendrickson, Pages 1 and 2). In a typical construction project, project scope is determined, an 
initial cost estimate is obtained, materials are procured, and tasks are scheduled. (Hendrickson, 
Page 5). Hendrickson notes the existence of potential conflicts and describes use of legal 
counsel and owner-controlled wrap-up insurance to protect parties from unforeseen risks. 
(Hendrickson, Page 13). Hendrickson describes changes in the organizational nature of a 
construction project (i.e. the interactions, scheduling, etc. between differing service providers), 
and changes in design plans during construction (Hendrickson, Pages 27, 28, 39, and 40). 
Specifically, Hendrickson notes that the initial estimated duration and cost of a project can vary. 
(See, e.g. Hendrickson, Pages 47, 87-103, 224, 233-237, and 315). Hendrickson further 
describes that economic evaluation of projects that relies on estimated costs can be hindered by 
risk, which can be mitigated through statistics and acquired knowledge from previous data. 
(Hendrickson, Pages 140, 141, and 191). However, Hendrickson does not disclose identifying 
discrepancies within a complex transaction, between estimated data, as defined by Applicant, 
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and actual performance data, as defined by Applicant, and receiving proposed reconciliation of 
these discrepancies and approval or disapproval thereof. Hendrickson instead relies upon 
conventional dispute resolution, such as through legal adjudication. (Hendrickson, Pages 220 
and 221). 

Thus, Hendrickson also fails to teach each element of the claims. Specifically, 
Hendrickson does not describe obtaining estimated data comprising an initial estimate of goods 
and/or services required for performance of at least a portion of a complex project, and 
comparing this estimated data with actual performance data comprising an indication of goods 
and/or services actually used for performance. Additionally, Hendrickson fails to teach or 
suggest receipt of a proposed reconciliation and approval or disapproval thereof should a 
discrepancy from the initial plan occur. Hendrickson instead relies upon conventional methods 
for scheduling and financing numerous, discrete, non-complex projects relating to construction, 
and conventional legal adjudication and similar methods for negotiating deviations from initial 
estimates. 

Conclusion 

In light of the above discussion, Applicant respectfully submits that the application now 
stands in prima facie condition for allowance and courteously requests that this application be 
advanced to issue. The Applicant is of the opinion that no additional fees are required. However, 
if additional fees are required, the Commissioner is hereby respectfully authorized to deduct such 
fees from Deposit Account Number 13-2166. 
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The Examiner is respectfully invited to call the Applicant's representative at 713-355- 



4200, to discuss any matters that may arise, where such discussion may resolve such matters and 
place this application in condition for allowance. 



Respectfully submitted, 

Date: November 17, 2009 /Jacob S. Mattis/ 

Jacob S. Mattis 

Registration No. 58,833 

The Matthews Firm (Customer # 021897) 

2000 Bering, Ste. 700 

Houston, Texas 77057 

(713) 355-4200 - Telephone 

(713) 355-9689 - Facsimile 
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